Skip to content

Conversation

@vdusek
Copy link
Contributor

@vdusek vdusek commented Nov 20, 2025

Closes: #666

@vdusek vdusek requested a review from janbuchar November 20, 2025 12:25
@vdusek vdusek self-assigned this Nov 20, 2025
@github-actions github-actions bot added this to the 128th sprint - Tooling team milestone Nov 20, 2025
@github-actions github-actions bot added the t-tooling Issues with this label are in the ownership of the tooling team. label Nov 20, 2025
# START OF CRITICAL SECTION - no awaits here
# Acquire lock to prevent race conditions between concurrent charge calls
# (e.g., when Actor.push_data with charging is called concurrently with Actor.charge).
async with self._charge_lock:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, on its own, doesn't fix the issue of multiple interleaved, PPE-aware Actor.push_data calls. The lock would need to be held for the whole duration of the push_data+charge sequence.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, so I moved the lock to the Actor class, take a look.

@vdusek vdusek force-pushed the sync-actor-charge-calls branch from 976e481 to e34aeed Compare December 2, 2025 13:51
@vdusek vdusek requested a review from janbuchar December 2, 2025 13:51
Copy link
Contributor

@janbuchar janbuchar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

pushed_items_count = min(max_charged_count, len(data)) if max_charged_count is not None else len(data)
# If charging is requested, acquire the charge lock to prevent race conditions between concurrent
# push_data calls. We need to hold the lock for the entire push_data + charge sequence.
async with self._charge_lock:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory, this could still get interleaved with an Actor.charge call with an unrelated event, which would result in pushing more items than the user can afford.

A watertight solution would be to use a read-write lock where plain Actor.charge would acquire the read-lock and Actor.push_data would acquire the write-lock.

But since there is no built-in read-write lock for asyncio, we should probably just leave this the way it is 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

t-tooling Issues with this label are in the ownership of the tooling team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Synchronize Actor.charge calls to prevent race conditions in Actor.push_data

3 participants